Machine type communication is a form of data communication that involves one or more entities that do not necessarily need human interaction. A service optimized for machine type communication differs from a service optimized for human-to-human (H2H) communication. Typically, machine type communication services are different to current mobile network communication services as it involves different market scenarios, pure data communication, lower cost and effort, and a potentially very large number of communicating terminals with little traffic per terminal.
The terms Machine-to-Machine (M2M) and Machine-Type Communications (MTC) are used to describe use cases and illustrate the diverse characteristics of machine type communication service. M2M and MTC devices will be part of the next generation wireless networks to enable “internet of things”. Potential M2M and MTC applications include security, tracking and tracing, payment, health, remote maintenance/control, metering, and consumer devices. The main characteristics of machine type communication services include low mobility, time controlled, delay tolerant, packet-switched only, small data transmissions, mobile originated only, infrequent mobile terminated, MTC monitoring, priority alarm, secure connection, location specific trigger, network provided destination for uplink data, infrequency transmission, and group based MTC features.
The end-to-end application between an MTC device and an MTC server or between two MTC devices is provided by 3GPP LTE systems. A 3GPP LTE system provides transport and communication services optimized for MTC. MTC traffic, however, may not be controlled by the network/core network. For example, an MTC application may request many MTC devices to do “something” at the same time, resulting in a large number of M2M devices trying to access the wireless service during a very short amount of time. As a result, many MTC devices may send a large number of random access channel (RACH) preambles and thereby causing high RACH collision probability. In addition, when a core network entity goes down, there is no mechanism to postpone the MTC devices from continuous access attempts. Consequently, many MTC devices are roamers and may all move to local competing networks when their own serving network fails, which may potentially cause traffic overload in the not (yet) failed network(s).
FIG. 1 (Prior Art) illustrates a radio network congestion use case in an LTE network 100. LTE network 100 comprises a MTC server 110, a packet data network gateway (PDN GW) 120, a serving GW 130, two base stations eNB 141 and eNB 142, and a plurality of M2M devices. Radio network congestion occurs when massive concurrent data transmission takes place in some MTC applications, as illustrated in FIG. 1. One of the typical applications is bridge monitoring with a mass of sensors. When a train passes through the bridge, all the MTC sensors transmit monitoring data almost simultaneously. The same thing happens in hydrology monitoring during the time of heavy rain, and in building monitoring when intruders break in. Therefore, it is desirable that the network is optimized to enable a mass of MTC devices in a particular area to transmit data almost simultaneously.
FIG. 2 (Prior Art) illustrates a core network congestion use case in an LTE network 200. LTE network 200 comprises a MTC server 210, a packet data network gateway (PDN GW) 220, a serving GW 230, two base stations eNB 241 and eNB 242, and a plurality of M2M devices. For many MTC applications, a large number of MTC devices are affiliated with a single MTC user (e.g., MTC user 250). These MTC devices together are part of a MTC group (e.g., MTC group 260). For example, MTC user 250 is associated with MTC group 260, and MTC user 250 owns MTC server 210. The MTC devices in MTC group 260 communicate with MTC server 210. Typically, the MTC devices in the same MTC group are scattered over the network in such a way that the data simultaneously sent by the MTC devices in any particular cell is limited and will not cause a radio network overload. However, when a high number of MTC devices are sending/receiving data simultaneously, data congestion may occur in the mobile core network or on the link between the mobile core network and the MTC server where the data traffic related to the MTC group is aggregated, as illustrated in FIG. 2. Therefore, it is desirable that a network operator and the MTC user have means to enforce a maximum rate for the data sent/received by the same MTC group.
Access Class Barring (ACB) is a mechanism to limit the number of simultaneous access attempts from certain MTC devices. All UEs (e.g., MTC devices) are member of one out of ten randomly allocated mobile populations, defined as access class 0 to 9. The population number is stored in UE's SIM/USIM. In addition, the UEs may be members of one or more out of five special categories (e.g., Access Class 11 to 15), also stored in the SIM/USIM. Under the ACB mechanism, the network operator may prevent certain UEs from making access attempts or responding to pages in specific areas of a PLMN based on the corresponding access class. In addition to the ACB mechanism, other enhanced access control solutions are sought for optimized MTC services.